개요

Kubernetes 환경에서 애플리케이션 서비스는 다양한 이점으로 활용할 수 있는 Ingress 를 선호하고 있으며 가장 많이 활용되고 있습니다. 가장 효율적인 애플리케이션 서비스 네트워킹을 위한 다양한 솔루션의 조합이 필요하며 이런 솔루션들의 조합은 아키텍처 및 운영의 복잡성을 야기시킬 수 있습니다. F5 의 CIS(Container Ingress Service)와 NGINX Ingress 의 자동화된 조합 및 가시화를 통해 가장 심플하고, 효율적인 서비스 네트워킹을 구성할 수 있습니다.

f5
nginx 인수

발표

k8s 서비스 네트워킹

보통 클러스터의 앱을 서비스 하기 위해서는?
노드포트를 뚫고, 이걸 노출시킨다.
물론 단순히 이렇게하면 토폴로지 종속된다.

그래서 csp면 로드밸런서를 둘 수 있다.
이 경우 vip에 대한 수요가 커진다.
이것 대신 ingress를 활용할 수도 있다.
l7 로드밸런서 역할

최근에는 한계가 와서 Gateway API가 생겼음

인그레스 심화

인그레스 기능

• l4, l7 기반의 인그레스, 이그레스 트래픽 라우팅
• 트래픽 제어
• api 게이트웨이(grpc)
• sso, jwt 인증
• 웹 방화벽

인그레스는 공항, 서비스는 비행기, 파드는 사람이다.
인그레스 컨트롤러가 관제탑 역할읋 하고 이를 토대로 인그레스 객체가 작동함

보안을 인그레스에서 챙기는 것이 좋다.
이 관제탑은 보안 영역에서 허가되징 않은 접근을 막을 수 있어야함
주기적인 상태 체크를 통해 블랙홀 라우팅도 방지하한다.
다만 east, west 와 같은 서비스간 트래픽을 관리하지는 않는다.
이것은 서비스 메쉬가 필요함

다른 유형의 인그레스

f5의 물리적 로드밸런서를 활용한다면?
사실 클러스터 내부에 그렇게 로드밸런서가 필요하겠는가?
이에 대해 f5에서는 cis 객체를 내부에 배포하여 활용한다.
이 컨트롤러가 외부의 adc 장비를 감지하고, 바로 필요한 파드에 트래픽을 전송한다.
외부 adc를 인그레스 타입으로 내부에서 정의한다.
그래야 상호작용이 가능하기 ㄴ할 듯
인그레스가 아니라 로드밸런서 서비스로 사용도 가능함

참고로 cni는 필요하다.

멀티 클러스터를 사용하는 회사도 많다.
이때 매번 인그레스를 두고 서비스를 배포할 것인가?
f5의 cis 컨트롤러는 그럴 필요가 없다.
단일 인그레스로 멀티 클러스터 서비스 지원!
(근데 이럴 거면 멀티 클러스터를 왜 구성하지)

gslb api를 활용해 dns도 필요없이 필요한 파드나 서비스에 접근하는 것도 가능

k8s 서비스 네트워킹 자동화

그래도 누군가는 nginx를 쓸 것이다.
이럴 때 nginx와 외부 adc를 연결할 수 있다.
이때 ingresslink resource를 배포하면 이 연결이 자동화된다.
netops, devops 직원이 일할 필요가 없다..!
퍼블릭 클라우드와 동일한 서비스 딜리버리 경험을 할 수 있음(엔지니어 입장에서)

참고